Fix the timeline trace lock so a window behind another writer persists - #2709

Verdict: PASS at ddba790
Written-by: Reviewer
Attestation: ddba790 role=Reviewer

Ran at this tip:

$ cd plugins/timeline && TZ=UTC DSH_HARNESS=/data/dsh/bot/workspace/d2607/repo/core/dev/harness node --import ./test/resolve.mjs --test "test/*.test.js"
# tests 161  # pass 161  # fail 0
$ cp base-store.js plugins/timeline/src/store.js; cp base-timeline.js plugins/timeline/src/timeline.js; cd plugins/timeline && TZ=UTC DSH_HARNESS=/data/dsh/bot/workspace/d2607/repo/core/dev/harness node --import ./test/resolve.mjs --test test/trace-lock-retry.test.js
# tests 3  # pass 1  # fail 2

Red first: with store.js and timeline.js from the base blob (42ef4703) and the new test kept, 2 of 3 cases go red — a window that started behind another writer persists once that writer leaves (persist stayed false) and a flush that still cannot take the lock answers false and names it once (true !== false, a dropped span reported as a successful flush). At the tip both pass.

Review points:

• A timeline trace that started behind another writer never retries the lock, and flush() reports success while dropping spans #2706 F4: retry + honesty, not "drop data and report success". store.js:192 asks for the lock again on flush() (and the flush timer while deferred); store.js:158 adopts the segments already on disk and appends the deferred records after them, so the first writer's history is kept. While the lock is still held, flush() returns false and warns once per process (store.js:195-200) instead of answering ok.
• Reverse control is real: test 1/2 read the segment files back (traceText()), and assert the second window's span (after-the-writer-left) is on disk together with first-writer; not just a stats flip.
• timeline.js: stats().persist stays a boolean (store.js:276; the extra deferred key appears only while deferred and renames nothing), stats.persisting in the window view now follows it, so client.js:630's persisting === false notice still fires correctly. openTrace({retryLock:true}) is opt-in from timeline.js:22 alone; every other caller keeps the base refuse-on-live-lock behaviour, and flush()'s new false answer is stated in the PR body.
• Lock discipline is unchanged from base: same acquire() and alive(pid) stale-lock takeover, release on close() and on a refused open; no new "anyone may steal" path. The .corrupt handling is the base load() moved verbatim, still covered by the suite.
• New test is genuine: spawn(process.execPath, ...) child processes, one real trace dir and one real writer.lock, disk assertions, and warn counted once.
• Range: only plugins/timeline/src/store.js, plugins/timeline/src/timeline.js, plugins/timeline/test/trace-lock-retry.test.js, changelog.d/2706-trace-lock.fixed.md; base = live main 42ef4703; core/**, plugins/workflow, plugins/social untouched. Check-runs at the tip: all success except enqueue-guard (no PASS yet — this comment is the PASS).